The invention relates generally to debugging computer programs and more particularly to graphically debugging computer programs.
The design and use of computer hardware and software programs are well known in the art, and need not be described here in any great detail. The following overview is presented merely to provide a context within which the present invention may be understood.
A computer program is a set of instructions that directs the functioning of various computer hardware resources in order to accomplish a particular task. In order to run a computer program, that program is typically loaded into the computer""s main memory, where each instruction within the program is stored at a unique location, specified by an address. The group of address locations occupied by the program is referred to as the instruction space of the program. During program execution, the computer""s control unit generally fetches and executes instructions in sequence. Fetching begins at a predefined start location within the program, and continues in sequence unless some type of branch instruction is encountered, or some other event, such as an interrupt, occurs. Branch instructions and interrupts will cause the control unit to begin fetching instructions from a new location that is not the next sequential instruction address within the instruction space. Program execution then proceeds in sequence beginning at this new memory location, until another branch or interrupt is encountered.
Although each computer instruction is really a set of electrical signals, each of which typically assumes one of two values, those who create, or write, computer programs (e.g., programmers or developers) usually use symbols that represent the various possible combinations of electrical signals. At the lowest level, these symbols may simply be a string of ones and zeroes, representing on a one for one basis each of the electrical signals that make up an instruction. More often, however, these symbols comprise alphanumeric characters which are arranged to form mnemonics in a programming language, each mnemonic representing an instruction or part of an instruction.
Prior art development environments used programming languages (or xe2x80x9cscripting languagesxe2x80x9d) to control the flow of an application. The languages allowed programmers to develop computer programs by utilizing the programming language to produce textual source code. That is, programmers utilized the programming language to produce textual source code made up of instructions, such as xe2x80x9cif-thenxe2x80x9d statements.
More recently, graphical development environments are being utilized by programmers to develop computer source code using icons to represent various language components, such as a while-loop, an if-branch, or a user-defined subroutine. For example, a graphical development environment may allow a programmer to place an icon in a program that represents an xe2x80x9cif-thenxe2x80x9d statement, rather than typing the textual source code for such an instruction. Such icons may be logically arranged to create the program flow for a program. Typically, a graphical development environment represents a program flow as a sequence of icons connected by arrows. An example of such a graphical development environment is provided in co-pending, commonly assigned U.S. application Ser. No. 08/599,134 filed Feb. 9, 1996, entitled xe2x80x9cENHANCED GRAPHICAL DEVELOPMENT ENVIRONMENT FOR CONTROLLING PROGRAM FLOW.xe2x80x9d Typically, graphical development environments allow a programmer to view the underlying source code represented by a particular icon if the programmer so desires. For example, a developer may simply double-click on an icon to reveal the underlying textual source code represented by that particular icon.
In recent years, software has had increasing importance in the computer industry. Software is used to control many increasingly complex processes, and the software itself has in turn become increasingly complex. Accordingly, computer program developers must ensure that their programs actually perform the task(s) that they are designed to perform. The act of making this determination is generally referred to as testing the software, and the act of identifying the cause of an identified problem, or a xe2x80x9cbug,xe2x80x9d in a program is generally referred to as xe2x80x9cdebuggingxe2x80x9d the software.
Traditional debugging methods include slow manual processes such as inserting print statements into the software at particular locations so that the values of variables and the like may be checked to determine if they have the expected values. That is, a programmer may insert print statements in the textual source code of a program to check the values of variables or other information at certain points in the execution of the source code.
To facilitate the debugging process, computer programs called xe2x80x9cdebuggersxe2x80x9d have been created. A typical debugger supplies a program control interface to the programmer that allows the programmer to do such things as executing only one program instruction at a time (referred to as xe2x80x9csingle steppingxe2x80x9d the program), determining what the next instruction to be executed is, examining and/or modifying computer register and memory locations, and setting breakpoints at particular locations within the program, whereby computer program execution will continue unimpeded until the breakpoint is the next location in the program that is to be executed by the computer. These features, and others, greatly assist the programmer in determining whether the sequence of program instruction execution is as expected, and whether the correct data is being moved from one computer resource to another. This view into the actual operation of the program allows the programmer to identify errors made in the program design in order to xe2x80x9cdebugxe2x80x9d the program.
A debugger is generally a tool that aids software development by giving the programmer control over and access to information about a running program. Debuggers typically run as self-contained processes, controlling the program under study (i.e., the application program) through operating system primitives designed for that purpose. A simple application program typically consists of data, and functions that operate on those data. Data and functions are defined in a source file created by the programmer (i.e., the xe2x80x9csource codexe2x80x9d). Each datum is associated with a type that describes its internal structure and behaviors; for example, integers may be 16 bits long, and may be added, subtracted, multiplied, etc. A tool called a compiler or translator reads a source file and produces an object file. The compiler typically works in conjunction with other toolsxe2x80x94assemblers, linkers, and optimizersxe2x80x94to accomplish this task, although such ancillary tools may be invisible to the programmer.
The object file contains bits which can be loaded into computer memory and executed; these bits include both the data and the machine instructions generated from the original program. These bits, when loaded into memory, are called the program image. In most systems, there is a close mapping of program image onto what the user perceives as a user process. The object file also contains a table that maps some of the original source information, as variable and function names, onto addresses, offsets, sizes, and other pertinent properties of the program image. This so-called symbol table is usually not made part of the program image itself, but remains in the object file where other programs (like the debugger) can read and analyze it.
A debugger is generally used to examine the program image of a program in execution, and to control the execution of the program. Because the debugger generally has access to the symbol table, it allows the user to interact with the target process (i.e., the application program) in terms of the names found in the source code. For example, if the user knows the name of a variable, the user can ask the debugger to retrieve that variable""s current contents from the program image or from storage dynamically allocated at run time by giving the variable""s name. By going to the symbol table and looking up the variable""s address and type, the debugger obtains the information it needs to satisfy the user request. An analogous scenario might allow the user to modify the value of a variable""s contents on the fly.
A debugger can generally arrange to perform certain debugging operations when the target program counter reaches some pre-specified address. The debugger can deposit a machine instruction at that address, designed to cause some trap or to cause an operating system service to be called when it is executed. By virtue of prior arrangements between the debugger and the operating system, several things may happen when the target reaches one of these instructions, including: 1) execution of the target process is put aside (i.e., the target process is stopped); and 2) the debugger is notified of the event and gains control. The debugger is typically able to determine the location of the event by examining program image state information saved by the operating system. Such special instructions, or the loci of such instructions, are called breakpoints. The event of execution arriving at a breakpoint is called the firing of a breakpoint.
Breakpoints are usually set at the direction of a programmer, who may want to know if and when execution reaches a certain point in a program, and may further wish to examine state information after the breakpoint fires. The programmer typically specifies where to insert the breakpoint, such as upon entry to a function or at a location corresponding to some line number in the source code. Current debuggers generally require that a programmer insert a breakpoint, or other debug tool, directly in the textual source code of a program. That is, if a programmer desires to insert a breakpoint just prior to the program performing a particular function, the programmer must find that particular function within the textual source code and insert a breakpoint indicator within the textual source code. A breakpoint indicator is generally inserted into the textual source code of a program by pressing a particular sequence of keys or by choosing to insert a breakpoint from a toolbar provided by the debugging program.
Generally, even programmers using graphical development environments are required to access the textual source code of a program in order to use debugging tools, such as breakpoints. That is, a programmer using a graphical development environment will typically be required to view the textual code underlying the graphical icons and set breakpoints or other debugging tools within the textual source code. Therefore, prior art debugging tools are utilized in much the same way by programmers, regardless of whether the programmer is using a textual development environment or a graphical development environment.
The operation of debugging programs is well known in the art. Such debugging programs are often included along with a particular programming language, such as C, C++ or Pascal. When debugging an application written in some programming languages, well known underlying operations typically used in debugging programs to perform certain debugging functions may be utilized within the graphical debugging environment disclosed herein. That is, for some programming languages the specific operations performed by a debugging program to accomplish performance of a breakpoint or to accomplish stepping through a program, as examples, may be utilized within the graphical debugging environment disclosed herein. For other programming languages, a particular method for performing the underlying operations may be required. For example, a debug engine may be utilized to perform the underlying operations, as discussed in greater detail hereafter. The present invention is intended to encompass both programming languages capable of being debugged using well known underlying operations within the graphical debugging environment, as well as those languages that require a specific method, such as a debug engine, to perform the underlying operations for a debugging tool.
Several problems exist with the prior art methods of debugging computer programs. As discussed above, one debug method requires inserting print statements throughout the source code of a program. Such an approach is no longer desirable because it results in very high overhead and intrusion on the operation of the code being examined. When a problem occurs in a program, the programmer inserts the print statements in essentially a hit and miss way in order to try to locate the error. When the program first fails, there are normally no print statements in the code that would indicate to the programmer where to look for the error. Thus, the programmer must either use some separate method to find the general location of the error, or scatter print statements at random throughout the program in the hope that at least one print statement will provide some clues about where the problem lies. Of course, the more subtle the problem, the less likely the programmer is to choose the proper location for a print statement on the first try. Therefore, at the outset at least, the programmer has no logical place to start the debugging process.
In order to collect a significant amount of data from which to look for symptoms of an error, the programmer must insert a large number of print statements. Accordingly, a great deal of time may be spent creating these statements. Moreover, for a program developer to use the print statements effectively, the developer must be intimately familiar with the source code of the program. That is, because the developer must physically insert the print statements in certain locations of the source code, the developer must be familiar enough with the code to understand where to effectively insert such print statements. A developer may be debugging a program that was written by the developer a fairly long time ago or that was written, in part or entirely, by another programmer. Therefore, it may be very difficult and time consuming for the developer to decipher the textual source code to determine where to best insert print statements.
An additional problem with using print statements to debug a computer program is that such print statements cannot be inserted into the program during runtime of the program. Inserting print statements typically requires that all or part of the program be recompiled and relinked, which may be a time consuming process. Likewise, when the programmer decides to remove a print statement, typically the program must be recompiled and relinked again. This also takes time. Once the print statement is removed, it may not be reinserted without again recompiling. Thus, each insertion or deletion of a print statement requires that a program be halted (if it was running), recompiled, and then restarted. Therefore, utilizing print statements to debug a program requires significant time and effort on the part of a programmer.
Also as discussed above, debugging programs have been developed to assist programmers. A problem with the prior art debugging programs is the way in which breakpoints and other debug tools must be used by a programmer. More specifically, the prior art debugging programs require a programmer to be intimately familiar with and interact with the textual source code of an application program in order to effectively utilize such debugging programs. For example, if a developer wants to use a breakpoint to debug a particular program, the developer must select a particular line of the textual source code and insert a breakpoint indicator at the selected line of the application program. Therefore, just as with inserting print statements to debug a program, utilizing prior art debugging programs requires that the developer be intimately familiar with the textual source code of the program. This problem is compounded when it is considered that most programs today are written in textual programming languages, without any graphical representation of the operation of the program to assist a programmer in understanding the program flow. Therefore, the programmer must read through lines and lines of textual source code prior to even making the initial decision of where to effectively place a breakpoint or other debug tool.
Even if a programmer is using a graphical development environment, prior art debugging programs still require the programmer to insert a breakpoint or other debug tool in the textual source code underlying the graphical icons. That is, programmers must interact with the textual source code represented by the graphical icons in order to effectively utilize prior art debugging programs. This is particularly problematic because programmers using a graphical development environment are required to become intimately familiar with the underlying textual source code in order to effectively debug an application using prior art debugging tools. Such programmers may be only accustomed to working with graphical icons to develop a program, and may not be accustomed to working with the textual source code underlying each icon. Accordingly, such debuggers defeat much of the purpose of having a graphical development environment because the programmers are still required to become intimately familiar with the underlying textual source code. In some cases, programmers using graphical development environments may find it especially difficult to debug an application by interacting with the underlying textual source code because such programmers may not be familiar with the underlying textual source code language. Rather, such programmers are typically more familiar and accustomed to developing the application program through a graphical environment.
An additional problem with using prior art debugging programs to debug a computer program is that such debugging programs generally do not allow breakpoints or other debug tools to be inserted into a program, removed from a program, or modified (such as modifying a debug tool""s state or conditions associated with a debug tool) during runtime of the program. Inserting, removing, or modifying breakpoints or other debug tools generally requires that a program be halted (if it was running), and then the program must be restarted thereafter. That is, prior art debugging programs generally require an application""s execution to be halted before inserting, removing or modifying a debug tool in the source code of an application program, and then execution of the application program must be restarted after the debugging tools have been inserted, removed or modified to perform the desired debugging of the application program.
Yet another problem with using prior art debugging programs to debug a computer program is that such debugging programs generally only allow one application program to be debugged at a time. That is, a program developer typically cannot debug multiple programs concurrently within prior art debugging programs. Accordingly, a program developer""s efficiency is limited because the developer is unable to effectively multi-task in debugging multiple programs. Rather than debugging multiple programs concurrently, a developer is required to debug only a single application program at a time with prior art debuggers.
In view of the above, there exists a desire for a method and system for debugging computer programs. There is a further desire to provide a method and system for debugging computer programs which allow a programmer to insert breakpoints and other debug tools graphically. That is, there exists a desire for a method and system for debugging computer programs which allow a programmer to insert breakpoints and other debug tools directly into a graphical representation of a computer program without being required to interact with the underlying textual source code. There exists a desire for a method and system for debugging computer programs which allow a programmer to remove and modify existing debug tools by interacting directly with a graphical representation of a computer program, rather than being required to interact with the underlying textual source code of the program.
Furthermore, there exists a desire for a method and system for debugging computer programs which allow a programmer to insert breakpoints and other debug tools into a graphical representation of a computer program during the program""s runtime. Likewise, there exists a desire for a method and system for debugging computer programs which allow a programmer to modify attributes of existing debug tools and remove (i.e., clear) debug tools from a graphical representation of a computer program during the program""s runtime. There is a further desire for a method and system for debugging computer programs which allows graphical debugging of multiple application programs concurrently.
These and other objects, features and technical advantages are achieved by a system and method which allow a programmer to perform debug tool management by interacting directly with a graphical representation of a computer program. More specifically, a graphical debugging environment is disclosed, which allows a program developer to insert, remove, and modify breakpoints and other debug tools by interacting directly with a graphical representation of a computer program.
In a preferred embodiment, a graphical representation of an application program to be debugged is displayed to a developer. For example, underlying source code of the application program may be represented by interconnected icons. Such a graphical representation may represent a computer program that is stored either locally or remotely. Additionally, such a graphical representation may represent a program that is currently executing either locally or remotely, or the graphical representation may represent a program that is not currently executing. A developer may then utilize the graphical debugger environment to insert debugging tools, such as breakpoints, directly into the graphical representation of the application program.
Advantageously, the developer is not required to insert such debugging tools into the underlying textual source code of the application program, but can insert the debugging tools directly into the graphical representation of the application program. Once the debug tools are inserted into the graphical representation of the application program, the debug tools themselves may be represented graphically to indicate which tools are currently set in the program and the point of the program at which each tool is currently set. In a preferred embodiment, the debug tools, such as breakpoints, may be set while the application program being debugged is executing, without requiring that the application be halted. Likewise, a preferred embodiment also allows for such debugging tools to be modified or removed from the application program without requiring that the application be halted.
Moreover, in a preferred embodiment, a developer may debug multiple programs concurrently utilizing a graphical debugging environment. Thus, a developer may simultaneously debug a number of programs in such a graphical debugging environment. Accordingly, a developer may insert and remove debug tools and otherwise monitor and interact with multiple programs concurrently.
It should be appreciated that a technical advantage of one aspect of the present invention is that a system and method for debugging computer programs graphically are provided wherein a developer is not required to interact with the textual source code of an application program in order to debug it. Accordingly, a developer may utilize the debugging tools more effectively by interacting directly with a graphical representation of the application program.
A further technical advantage of one aspect of the present invention is that a system and method for debugging computer programs graphically are provided wherein an application program is not required to be halted in order to insert debugging tools into the program and effectively debug it. Likewise, a technical advantage of one aspect of the present invention is that a system and method for debugging computer programs graphically are provided wherein an application program is not required to be halted in order to modify or remove debugging tools from the program. Accordingly, a developer may effectively debug an application program without being required to halt the program by, for example, inserting breakpoints while the program is running.
Still a further technical advantage of one aspect of the present invention is that a system and method for debugging computer programs graphically are provided wherein an application that is stored and/or executing remotely can be debugged utilizing a debugging program that is executing locally. Accordingly, a debugging program is not required to be executing at each remote site where an application program is stored and/or executing.
Yet a further technical advantage of one aspect of the present invention is that a system and method for debugging computer programs graphically is provided wherein multiple application programs may be debugged concurrently utilizing a graphical debugging environment.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.